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Beschreibung 

Verfahren zur Aufwandsbeschrankung bei der Ubertragung von 
unidirektionalen Informationsstromen 

5 

Die Erfindung betrifft ein Verfahren zur Reduzierung des Auf- 
wands der Bearbeitung von in Richtung einer Kommunikations- 
vorrichtung iibertragenen Nutzdaten in Fallen, bei denen im 
Rahmen eines Dienstes eine bidirektionale Verbindung zwischen 
10 der Kommunikationsvorrichtung und einer Kommunikationspart- 
nerinstanz eingerichtet wird, obwohl der Dienst keine Nutzda- 
tentibertragung zu der Kommunikationsvorrichtung erfordert. 

Die Erfindung liegt auf dem Gebiet der Sprach- und Datenkom- 
15 munikation und beruhrt insbesondere Aspekte der Vermittlungs- 
technik. 

In der Kommunikationstechnik gibt es ein stetiges Streben 
nach Ressourcenef f izienz . Dabei spielen Einsparungen bei Kom- 

20 munikationsvorrichtungen zum Vermitteln und Verteilen von 
Nutzdaten eine wichtige Rolle. Bei der Reduzierung des Auf- 
wands und der Komplexitat derartiger Einrichtungen ist jedoch 
zu beriicksichtigen, dass Standards einzuhalten und die Kompa- 
tibilitat zu anderen Kommunikationsvorrichtungen gewahrt wer- 

25 den soil. Diese Anforderungen stehen der Reduktion der einge- 
setzten Mittel bzw. Ressourcen haufig im Wege. 

Ein wichtiges Beispiel fur Kommunikationsvorrichtungen mit 
einem Potential fur Einsparungen sind Vorrichtungen, deren 
30 Funktionalitat keine Bearbeitung von eingehenden Nutzdaten 
erfordert. Beispiele fur derartige Kommunikationsvorrichtun- 
gen sind: 

• Reine Informationsausgabesysteme, z.B. reine Ansagensyste- 
me. Bei Informationsausgabesystemen, welche nur die Ausga- 
35 be von Informationen (z.B. Sprachinformationen) vorsehen 
und nicht evtl* durch extern zugefuhrte Informationen 
steuerbar sind (wie z.B. Systeme zum interaktiven Sprach- 
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dialog) , konnen die Ressourcen zur Bearbeitung von zu dem 
System iibermittelten Informationen reduziert werden. 
• Reine Verteilsysteme. Verteilsysteme beschranken sich hau- 
fig auf das Weiterleiten bzw. Weitervermitteln von Infor- 
5 mationen bzw. Nutzdaten. Ressourcen fur die Interpretation 
bzw. Bearbeitung von Nutzdaten konnen in reduziertem Urn- 
fang vorgesehen werden. 

Die oben beschriebenen EinsparungsmaJSnahmen sind dadurch be- 
lt) grenzt, dass Kompatibilitat bei der Kommunikation mit anderen 
Vorrichtungen bzw. Endgeraten gegeben sein muss. So gibt es 
Kommunikationsinstanz en ( z . B . Endgerate , Vermittlungsvorrich- 
tungen oder Gateways) , bei welchen im Rahmen eines Kommunika- 
tionsvorgangs eine bidirektionale Verbindung vorgesehen ist, 
15 unabhangig davon, ob tatsachlich Nutzdaten zu der Kommunika- 
tionspartnerinstanz gesendet werden. Fiir Verbindungen zur 
Nutzdatenubermittlung zu einer derartigen Kommunikationsin- 
stanz mussen von Informationsausgabesystemen bzw. Kommunika- 
tionsverteilsystemen Ressourcen fiir die Bearbeitung von der 
20 Kommunikationspartnerinstanz ubermittelten Informationen vor- 
gesehen werden , um eine bidirektionale Verbindung zu ermogli- 
chen. 

Ein Beispiel fiir eine derartiges Szenario ist der Informati- 
onsaustausch zwischen einem reinen Ansagesystem und einem 
Endgerat, bei dem von dem Endgerat nur eine bidirektionale 
Verbindung unterstiitzt wird. Obwohl nur in einer Richtung 
(von dem Ansagesystem zu dem Endgerat) relevante Informatio- 
nen iibertragen werden, kommt auch in der anderen Richtung ei- 
ne Nutzdateniibertragung zustande, die z.B. in der Ubertragung 
von von einem Mikrophon des Endgerates aufgenommenen Hinter- 
grundgerauschen besteht. Der von dem Endgerat zu dem Ansage- 
system iibertragene Nutzdatenstrom bzw. Bearer-Strom ist dann 
fiir den Dienst irrelevant, erfordert aber Bearbeitungsres- 
sourcen auf Seiten des Ansagesys terns . 
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Zudem wird haufig bei einer bidirektionalen Verbindung von 
den verwendeten Protokollen vorgesehen, dass Informationen in 
beide Richtungen gesendet werden, welche statistische Aussa- 
gen iiber die Qualitat der Verbindung enthalten. Diese Infor- 
5 mationen werden z.B. dazu verwendet, die Sender ate zu regu- 
lieren. Eine beteiligte Koinmunikationsvorrichtung muss daher 
iiber Mittel zur Generierung dieser Informationen verfugen. 

Ein wichtiges Protokoll, bei dem die oben beschriebene Situa- 
10 tion vorkommen kann, ist das RTP (real time protocol) Proto- 
koll, welches in Verbindung mit dem RTCP (real time control 
protocol) verwendet wird. Das RTP Protokoll ermoglicht die 
Ubertragung von Sprache als Nutzdaten bzw. Bearer. Die Uber- 
tragung des Bearers wird durch das RTCP Protokoll gesteuert. 
15 Wenn beispielsweise ein Ansagesystem mittels dem RTP/RTCP 

Protokollstapel Sprachinformationen an ein Endgerat ausgibt, 
welches nur bidirektionale RTP Verbindungen unterstiitzt, wer- 
den mittels des RTCP Protokolls statistische Informationen 
iiber die Verbindung in beiden Richtungen ubermittelt. 

20 

Die Erfindung hat zur Aufgabe, eine Aufwandsreduzierung bei 
Kommunikationsvorrichtungen zu ermoglichen. 

Die Aufgabe wird durch die Gegenstande der unabhangigen An- 
25 spriiche gelost. 

Die Erfindung beruht auf der Beobachtung, dass fur Kommunika- 
tionsvorrichtungen, welche generell Oder fur bestimmte Diens- 
te keine Nutzdatenubertragung an eine Kommunikationspartner- 

30 instanz vorsehen, in Fallen, in denen trotzdem eine bidirek- 
tionale Verbindung zu der Partnerinstanz aufgebaut wird f bei- 
spielsweise weil die Kommunikationspartnerinstanz nur bidi- 
rektionale Verbindungen mit dem verwendeten Protokoll unter- 
stiitzt, der Auf wand bei der Bearbeitung, der von der Kommuni- 

35 kationspartnerinstanz xibertragenen Nutzdaten reduziert werden 
kann, indem zumindest ein Teil dieser von der Kommunikations- 
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partnerinstanz in Richtung der Kommunikationsvorrichtung ii- 
bertragenen Nutzdaten verworfen werden. 

Beispiele fur Vorrichtungen bzw. Dienste, fur die in der Re- 
5 gel nur Nutzdateniibertragung in einer Richtung, d.h. unidi- 
rektional vorgesehen ist, sind Inf ormationsausgabesysteme 
(z.B. Ansagesysteme) und Verteilsysteme bzw. Inf ormationsaus- 
gabedienste (z.B. Ansagedienste) und Verteildienste. Die Kom- 
munikationspartnerinstanz kann beispielsweise durch ein End- 
10 gerat oder ein Gateway gegeben sein. 

Die Erfindung hat den Vorteil von im Vergleich zur herkommli- 
chen Systemen gxoBerer Ressourcenef f izienz . Der Bearbeitungs- 
aufwand wird reduziert, indem ubertragene Nutzdaten, die fur 

15 den Dienst irrelevant sind, verworfen werden. Ein eventuell 
bei einer Sprachverbindung ubertragenes irrelevantes Hinter- 
grundger£usch wird in der Kommunikationsvorrichtung nicht 
vollstandig ausgewertet. Ein Teil der Hardware bzw. Software- 
res sourcen, die in der Kommunikationsvorrichtung herkommlich 

20 zur Bearbeitung von an die Kommunikationsvorrichtung tibertra- 
genen Nutzdaten vorgesehen sind, konnen eingespart werden. 
Dies kann teure spezielle Hardware, wie DSPs (DSP: digital 
signalling processor) oder ASICs (ASIC: application specific 
integrated circuit) betreffen. 

25 

Die Erfindung ist beispielsweise anwendbar in paketorientier- 
ten Netzen, uber welche Nutzdaten als Nutzdatenpakete in 
Richtung der Kommunikationsvorrichtung iibertragen werden. In 
diesem Fall lasst sich der Verwurf der Pakete z.B. auf fol- 
30 gende zwei Weisen realisieren: 

• Ein der Kommunikationsvorrichtung vorgelagerter Router 
verwirft die zu der Kommunikationsvorrichtung iibertragenen 
Nutzdaten. 

• In der Kommunikationsvorrichtung werden eintreffende Da- 
35 tenpakete gefiltert, z.B. anhand der UDP-Portadressen 

(UDP: user datagram protocol), und Nutzdatenpakete, welche 
von der Kommunikationspartnerinstanz gesendet wurden, wer- 
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den verworfen. Dieses Herausfiltern der nicht fur den 
Dienst relevanten Nutzdaten kann auf den unteren Schichten 
des Protokolls-tapels vorgenommen werden. Eine Bearbeitung 
auf den oberen Schichten des Kommunikationsprotokolls oder 
5 eine Auswertung bzw. Interpretation ubermittelter Nutzda- 
ten ist nicht erf orderlich, so dass daftir keine Ressourcen 
vorgesehen werden miissen. 

Die Nutzdatenpakete werden im Falle von Echtzeitverkehr bei- 

10 spielsweise raittels des RTP-Protokolls iibertragen. Fur die 
Steuerung von RTP-Verbindungen wird das RTCP-Protokoll ver- 
wendet. Gemafi dem RTCP-Protokoll werden statistische Informa- 
tionen zwischen den Kommunikationsinstanzen iibertragen, wel- 
che sich haufig auf die Ubertragungsqualitat der Nutzdaten- 

15 iibertragen der Konununikationsinstanzen bezieht. Herkommlich 
erfordert die Generierung solcher statistischer Informationen 
oder generell von Kontrollinformationen zur Verbindungsquali- 
tat die Auswertung der iibersendeten Nutzdaten, Die vorliegen- 
de Erfindung sietit allerdings vor, dass fur die angesproche- 

20 nen Falle ein Teil der Nutzdaten verworfen, also nicht auf 

die Obertragungsqualitat hin ausgewertet werden. Entsprechend 
einer vorteilhaf ten Weiterbildung kann verhindert werden, 
dass die Kontrolipartnerinstanz wegen ausbleibender oder ir- 
refiihrender Meldungen bzw. Informationen iiber die zur Kommu- 

25 nikationsvorrichtung aufgebauten Verbindung zu ungewiinschten 
Reaktionen - im Extremfall der Beendigung der bidirektionalen 
Verbindung - veranlasst wird. Dabei sendet die Kommunikati- 
onsvorrichtung Informationen bzw. Meldungen an die Kommunika- 
tionspartnerinstanz, die ein einwandf reies Funktionieren der 

30 Nutzdatemibertragung von der Kontrolipartnerinstanz zu der 
Kommunikationsvorrichtung simuliert. Dabei kann z.B. ein be- 
kannter Wertebereich fur die Kontrollinformationen benutzt 
werden, welcher einer storungsfreien Nutzdatenubertragung 
entspricht. Weiter ist es moglich, dass man einen kleinen 

35 Teil der Nutzdaten nicht verwirft, sondern fur die Berechnung 
statistischer Informationen bzw. Kontrollinformationen aus- 
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wertet und die erhaltenen Ergebnisse fur die gesamte Menge an 
Nutzdaten extrapoliert . 

Die Erfindung wird im Folgenden im Rahmen eines Ausfuhrungs- 
5 bei spiels anhand von Figuren naher erlautert. Es zeigen: 

Figur 1 : Eine Kommunikationsvorrichtung und eine Kommunika- 
tionspartnerinstanz, die miteinander kommunizieren, 
wobei von der Kommunikationspartnerinstanz zu der 
Kommunikationsvorrichtung ubertragenen Nutzdaten 
von einem Router herausgef iltert werden. 

Figur 2: Eine Kommunikationsvorrichtung und eine Kommunika- 
tionspartnerinstanz in Kommunikationsbeziehung, wo- 
bei von der Kommunikationspartnerinstanz an die 
Kommunikationsvorrichtung gesendete Nutzdaten in 
der Kommunikationsvorrichtung herausgef iltert und 
verworfen werden, 

Beide Figuren zeigen eine Kommunikationsvorrichtung IVR (IVR: 
Interactive Voice Response) und eine Kommunikationspartnerin- 
stanz KPI, welche uber eine bidirektionale Verbindung mittels 
des RTP-Protokolls Nutzdaten miteinander austauschen. Gesteu- 
ert bzw. kontrolliert werden diese Verbindungen mittels des 
RTCP-Protokolls. In Figur 1 ist ein Router R gezeigt, der mit 
Hilfe eines Filters F an die Kommunikationsvorrichtung IVR 
iibertragene Nutzdaten herausf iltert, so dass diese nicht zu 
der Kommunikationsvorrichtung IVR gelangen. In Figur 2 wird 
diese Filterfunktion von der Kommunikationsvorrichtung IVR 
selber vorgenommen, welche mit Hilfe eines Filters F von der 
Kommunikationspartnerinstanz KPI iibertragene Nutzdaten her- 
ausfiltert und verwirft, welche so nicht durch hohere Proto- 
kollschichten bearbeitet werden mtissen. 

35 Bei der Kommunikationsvorrichtung IVR handelt es sich bei- 
spielsweise urn ein Software-basiertes VoIP (VoIP: voice over 
IP) Ansagesystem auf Basis des RTP und des RTCP Protokolls. 
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Im Folgenden wird beispielhaft fur ein Ansagesystem beschrie- 
ben, wie man statt bidirektional betriebener RTP/RTCP Kanale 
mit unidirektional betriebenen Kanalen arbeiten kann. 

5 

Bei dem ersten Beispiel entsprechend Fig. 1 verwirft ein vor- 
gelagerter Router die RTP Pakete in Richtung Ansagesystem, so 
dass trotz bidirektionaler Durchschaltung das Ansagesystem 
nicht mit RTP-Last beaufschlagt wird. 

10 

Im Fall der Behandlung der Nutzdaten in dem Ansagesystem 
(Beispiel entsprechend Fig. 2) schaltet der die Verbindung 
steuernde Call Controller oder der entfernte Endpunkt einen 
symmetrischen RTP Strom durch das IP Netz zum Ansagesystem 

15 duzrch. Oberhalb des IP Stacks, d.h. des IP Protokollstapels 
im Ansagesystem, wird ein statischer Filter eingerichtet, der 
alle zum Ansagesystem ftihrenden mittels des RTP Protokolls 
ubertragenen IP Pakete anhand der durch diese Protokolle ver- 
wendeten UDP (user datagramm protocol) Ports erkennt und ver- 

20 wizrft. Die hoheren Protokoll Layer, die rechenzeitaufwendige- 
re Aufgaben fur diese Pakete durchfuhren nuissten, werden da- 
duirch nicht mehr belastet und mussen nur noch ausgehende Da- 
tenstrome behandeln. 

25 Da in einem Sof tware-basierten Ansagesystem ein sehr hoher 
Anteil der Performance auf die Behandlung von RTP Protokoll- 
ablaufe entfallt, kann das frei werdende Rechenzeit Budget 
nun z.B. zur Behandlung weiterer Ansage Ports verwendet wer- 
den . 

30 

RTCP sender reports werden wie in RFC 1889 (RFC: request for 
comments) vorgesehen ausgesendet. Der Standard sieht bereits 
voar, dass diese relativ selten ausgesendet werden, so dass es 
keines groJSen Rechenzeitaufwandes bedarf . Daher kann der Fil- 
35 ter RTCP Pakete an den RTCP Rrotokollstapel des Ansagesystems 
wei terleiten. 
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Entsprechend einer Weiterbildung des Anmeldegegenstands kann 
auf Ebene des RTCP Protokolls ein einwandfreies Funktionieren 
einer bidirektionalen Verbindung simuliert werden. Das RTCP 
Protokoll sieht das optionale Aussenden von sogenannten Re- 
5 ceiver Reports vom Ansagesystem zum entfernten Anwender vor. 
Da im Ausfiihrungsbeispiel ein Bearer bzw. Nutzdaten Strom 
physikalisch durch das IP Netz geschaltet wurde, kann man 
versuchen, die vom entfernten Mikrofon aufgenommenen und via 
der Kommunikationspartnerinstanz ubertragenen Sprachstrome 
10 oder Voice Activity Meldungen zu bewerten, urn dem entfernten 
Anwender, bzw. dessen Bearer Behandlung, einen Duplex Stream, 
d.h. eine bidirektionale Verbindung, vorzuspiegeln. 

Damit das Ziel der Aufwandsreduzierung, die durch Ausfuh- 
15 rungsbeispiel 1 erreicht wird, nicht konterkariert wird, ist 
es sinnvoll, auf eine kontinuierliche Berechnung der RTCP 
Statistiken auf Basis aller empfangenen RTP Pakete zu ver- 
zichten. Folgende Losungsansatze zur Reduzierung des Auf wands 
bei der Berechnung der RTCP Statistiken konnen beschritten 
20 werden: 

a) Aussenden eines default Reception Reports 

Da ein hier beschriebenes Ansage- oder Verteilsystem nicht 
25 von der Qualitat des empfangenen Stroms abhangig ist, konnen 
in den Report erf ahrungsgemafi akzeptable Standardwerte einge- 
tragen werden. Sollte ein Network Operator diese auswerten 
bzw. interpretieren, muss ihm der Umstand, dass speziell die- 
se Reports nicht aussagekraftig sind, lediglich im Rahmen der 
30 Definition der Standardwerte bewusst sein. Damit wird sicher- 
gestellt, dass das entfernte Bearer Treatment keine ungewoll- 
ten GegenmaBnahmen einleitet (z.B. die Senderate reduziert 
Oder Fehler Reports generiert) . Der Reception Report kann 
folgende Parameter (entsprechend RFC 1889) enthalten: 

35 

• SSRC (Synchronization source) der sendenden Quelle (kann 
aus beliebigen empfangenen RTP Paketen, z.B. mittels ei- 
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nes RTP Sniffers bzw. Filters, welcher wenigstens zu Be- 
ginn des Rufes/der Session einige Pakete auswertet, er- 
mittelt werden oder aus dem letzten empfangenen Sender 
Report ermittelt werden) 

• Lost Fraction : hier wird 256 eingetragen, was einem i- 
dealem Empfang entspricht. 

• Cumulated number of lost packages: hier wird 0 oder ein 
sehr geringer Wert eingetragen 

• Highest received sequence number: die Anzahl der Sequen- 
ce Number Cycles und der Highest Sequence Number Recei- 
ved wird aus einer Rundung einer algorithmischen Berech- 
nung aus 

- der Zeit seit dem letzten Reception Report (alternativ 
kann der Beginn der Bearer Durchschaltung zugrunde ge- 
legt werden) 

- dem Codec Type und seiner Bandbreite und 

- den verwendeten Paketisierungsgrossen (Ergebnisse der 
Codec Negotiation) 

mittels der zu erwartenden RTP Paketanzahl ermittelt. 
Diese Parameter sind bei Ansagesystemen pro Ruf/Session 
stabil und es ist daher eine derartige Berechnung / Fol- 
ge von Divisionen moglich. 

• Interarrival Jitter: hier wird ein unverdachtiger Wert, 
der 1 ms entspricht, eingetragen. 

• Last (arrived) SR: der Zeitstempel des letzten Sendere- 
ports wird von der RTCP Statistik Funktion fur Sender 
Reports ubernommen. 

• Delay since last (arrived) SR: die im letzten Sendere- 
port eingetragene Verzogerung wird von der RTCP Statis- 
tik Funktion fur Sender Reports ubernommen. 

b) Reduktion der Anzahl der RTP Pakete, die von der RTCP Sta- 
35 tistik Funktion bearbeitet werden muss 
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Kontrolliert iiber einen geeigneten, zeitlich gesteuerten dy- 
namischen Filter oberhalb des IP stacks (der auf RTP Port Ad- 
ressen sensibilisiert ist) , werden der RTCP Statistik Funkti- 
5 on nur RTP Pakete iiber einen beschrankten Zeitabschnitt (z.B. 
die Dauer eines Ansage-Rufs) , z.B. iiber mehrere gleichver- 
teilte 100 ms Intervalle der im Mittel 10 Sekunden lang dau- 
ernden Ansageverbindung zugestellt. Die RTCP ports sind hier 
prinzipiell of fen. 

10 

Hier kann im Wesentlichen eine kommerzielle RTCP Statistik 
wiederverwendet werden, die eine langere Messung als tatsach- 
lich erfolgt vortauscht. Der Parameter "Highest Received Se- 
quence Number" muss aber wie unter a) approximativ berechnet 
15 werden. Fur den "Interarrival Jitter und Lost Fraction" Para- 
meter konnen dagegen die aus der 100 ms Messung erzeugten 
Werte als die ,realen' Messwerte in den Reception Report ein- 
getragen werden. Der Parameter "Cumulated number of lost 
packages" muss ebenfalls extrapoliert werden. 

20 

Geht man z.B. von 1 Sekunde dauernden Intervallen fur das 
Aussenden der Reception Reports aus und misst man darin je- 
weils nur 100 ms, so ware der zu sendende Wert urn den Faktor 
10 zu multiplizieren. Man trifft hier die Annahme einer 
25 Gleichverteilung der Paketverluste iiber die Ruf dauer. 
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Patentanspruche 

1. Verfahren zur Reduzierung des Auf wands der Bearbeitung von 
in Richtung einer Kommunikationsvorrichtung (IVR) fibertrage- 
nen Nutzdaten in Fallen, bei denen im Rahmen eines Dienstes 
eine bidirektionale Verbindung zwischen der Kommunikations- 
vorrichtung (IVR) und einer Kommunikationspartnerinstanz 
(KPI) eingerichtet wird, obwohl der Dienst keine Nutzdaten- 
iibertragung zu der Kommunikationsvorrichtung (IVR) erfordert, 
demzuf olge 

zumindest ein Teil der Nutzdaten vor Durchfuhrung zumindest 
eines Teils der im Rahmen einer Bearbeitung von Nutzdaten 
vorgesehenen Arbeitsschritten verworfen wird. 

15 2. Verfahren nach Anspruch 1, 

dadurch gekennzeichnet , dass 

die Kommunikationsvorrichtung (IVR) durch ein Informations- 
ausgabesystem oder ein Verteilsystem gegeben ist. 

20 3. Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, dass 

die Kommunikationspartnerinstanz (KPI) durch ein Endgerat o- 
der ein Gateway gegeben ist. 

25 4. Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, dass 

die Nutzdaten als Nutzdatenpakete iiber ein paketorientiertes 
Netz in Richtung der Kommunikationsvorrichtung (IVR) iibertra- 
gen werden. 

30 

5. Verfahren nach Anspruch 4, 
dadurch gekennzeichnet, dass 

in einem der Kommunikationsvorrichtung (IVR) vorgelagerten 
Router (R) zumindest ein Teil der Nutzdatenpakete verworfen 
35 werden. 
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6. Verfahren nach Anspruch 4, 
dadurch gekennzeichnet , dass 

bei der Kommunikationsvorrichtung (IVR) ankommende Datenpake- 
te gefiltert werden und zumindest ein Teil der von der Kommu- 
5 nikationspartnerinstanz (KPI) ubertragenen Nutzdatenpakete 
verworfen werden, 

7. Verfahren nach Anspruch 6, 
dadurch gekennzeichnet, dass 

10 die von der Kommunikationspartnerinstanz (KPI) ubertragenen 
Nutzdatenpakete anhand ihrer Port Adressen identif iziert und 
herausgefiltert werden. 

8. Verfahren nach einem der vorhergehenden Anspruche 4 bis 7, 
15 dadurch gekennzeichnet, dass 

die Nutzdatenpakete mittels des RTP Protokolls iibertragen 
werden . 

9. Verfahren nach einem der vorhergehenden Anspruche, 
20 dadurch gekennzeichnet, dass 

von der Kommunikationsvorrichtung (IVR) an die Kommunikati- 
onspartnerinstanz (KPI) Informationen iibertragen werden, wel- 
che eine einwandfreie ttbertragung der Nutzdaten von der von 
der Kommunikationspartnerinstanz (KPI) an die Kommunikations- 
25 vorrichtung (IVR) simulieren. 

10. Verfahren nach Anspruch 9, 
dadurch gekennzeichnet, dass 

die Informationen die ttbertragungsqualitat der Nutzdateniiber- 
30 tragung von der Kommunikationspartnerinstanz (KPI) zu der 
Kommunikationsvorrichtung (IVR) betref fen . 

11. Verfahren nach Anspruch 9 Oder 10, 
dadurch gekennzeichnet, dass 

35 die Informationen mittels des RTCP Protokolls iibertragen wer- 
den. 
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12. Kommunikationssystem (IVR) zur Durchfiihrung eines Verfah- 
rens nach einem der Anspriiche 1 bis 11, 
gekennzeichnet durch 

einen Filter zur Identif izierung von von der Kommunikations- 
5 partnerinstanz (KPI) zu der Kommunikationsvorrichtung (IVR) 
xibertragenen Nutzdaten. 

13. Router (R) zur Durchfiihrung eines Verfahren nach einem 
der Anspriiche 5 bis 11 

10 gekennzeichnet durch 

Mittel zur Verwerfung von von der Kommunikationspartnerin- 
stanz (KPI) zu der Kommunikationsvorrichtung (IVR) ubertrage- 
nen Nutzdatenpaketen. 
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FIG 2 

RTCP 



